Ryuzee氏に学ぶ『エンジニアリングマネージャーのしごと』 #Forkwell_Library

#レポート

quiver

2022.09.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

近年は、エンジニアを束ねるエンジニアリングマネージャー(EM)を採用する組織が増えています。デリバリーに軸足を置くプロダクトマネージャーに対して、EMはエンジニアのピープルマネージメントに軸足を置いています。

そんなEM渇望の一冊が、先月末にオライリーから出版されました。

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 : James Stanier

社内でも、今週月曜から部門横断の読書会が始まったばかりです。

その翌日に、Forkwell のイベントで同書の翻訳に関わった吉羽龍太郎/@ryuzee 氏によるエンジニアリングマネージャーに関する講演を視聴する機会がありましたので、かんたんにレポートを共有します。

Forkwell イベント概要

エンジニアリングマネージャーのしごと - Forkwell Library #5 - connpass

公式レポート:「権限移譲できてる？エンジニアリングマネージャーのしごと」吉羽龍太郎 | エンジニアの生き様をウォッチするメディア

「つぎの一歩が見つかる、気づきと学びの場」 Forkwell Library シリーズ第5弾

これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。

しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。 Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。

今回の第5回目では2022年8月26日に出版の最新刊『エンジニアリングマネージャーのしごと』を取り上げます。翻訳者である吉羽龍太郎氏をお招きしてエンジニアからエンジニアリングマネージャーになるためのノウハウをお聞きしていきます。

【資料公開】エンジニアリングマネージャーのしごと | Ryuzee.com

吉羽龍太郎/@ryuzee 氏について

吉羽氏は

日系SIer新規事業部門
外資系クラウドベンダー。コンサルティング部門

で技術系部門のマネージャーを経験されています。数多くの技術書の翻訳に携わり、氏の技術・組織などに関する文章・講演に触れた人も多いのではないでしょうか。

DevelopersIOでも過去に長文インタビューを掲載しています。

アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) | DevelopersIO

レポート

時間的制約から、網羅性や細かいプラクティスの紹介は控え、根底の考え方に近いところにフォーカスしています。

エンジニアリングマネージャーとは?

エンジニアリングマネージャーは4領域にまたがるマネージメント
- ピープル
- テクノロジー
- プロジェクト
- プロダクト
軸はピープルマネジメントで、チームメンバーのマネージメントが職務の中心。
特に、人事評価権限を持つ
一般に人事評価権限を持たない、テックリード、プロジェクトマネージャー、プロダクトマネージャーなどとは大きく異なる

ピープルマネージャーとプロジェクトマネージャーを同一人物がやるの無理筋だ、っていつも言ってるんだけどな。だいたい外圧に負けてプロジェクトしか考えなくなって詰んじゃう

— Ryutaro YOSHIBA (@ryuzee) September 1, 2022

デリバリーとピープルマネージメントの兼任は最大のアンチパターン
プロジェクトマネージャーとピープル(エンジニアリング)マネージャーを兼任してはいけない
利害相反。時間的な問題も
両方どっちつかずはまずい
プロジェクトマネージャーはデリバリーの責任を負う
- スコープ・納期・お金を守る
ピープルマネージャーとしてはメンバーの成長、働きがい、持続可能性の責任を負う
デリバリーの強い外圧に負けると、チームを犠牲にしてしまいがち
SIerではこの2つのロールを兼任するケースが多い
人を分けること

余裕を持つ

EMはいつも

時間がなくて忙しい
成果を出せている感覚を持てない

などと言っている。

余裕を持つ
- ワインバーグもいっているように、稼働率100％だと、何かあったときに、問題に対処できない。
- いざとなったら出動できるよう、キャパシティに余裕を持たせなければいけない。
整理整頓
- 自分の仕事をうまく効率・構造化し、自分自身が整理整頓された状態にしておく。
- 時間の無駄を省いて、キャパシティを確保することにもつながる
重要な仕事にフォーカス
- 本当に重要な仕事に自分の脳みそを使う。
- 一部のテック系著名人がも、いつも同じ服、同じ食べ物を食べているのも、余計なことで脳みそを使わないようにするための、同様の配慮かもしれないない。
マネージャーはチームを管理するのに、自分自身が管理できていないようでは、論外
マネージャーには考える時間が必要。そのための時間を予めブロックしておくこと

マネージャーのアウトプット(アウトカム)

マネージャーのアウトプット = 自分のチームのアウトプット + 影響を与えた他のチームのアウトプット

マネージャーは自身のパフォーマンスを上げるよりも、チームのパフォーマンスを上げることが大事
他のチームに悪影響を与えてまで、自分のチームのアウトプットを上げると、アウトプットの総量が下がる

マネージャーの日々の仕事

以下の4カテゴリーがある

情報収集:意思決定の土台
意思決定:マネージャーの言葉・意思決定は重いので慎重に。意思決定を先延ばしても問題になる
ナッジング:自分の知識を与えて、他者の意思決定を促す
ロールモデル:周りに行動で示す

委譲する

なぜ委譲する?

何でもかんでも自分でやるのは良くないし、そもそも無理。
自分のタスクを他の人にやってもらうのが、マネージャーの重要な活動
委譲できるのは実行責任までであり、最終的な説明責任は自分が負う。

委譲には段階がある

委譲は0，1ではなくグラデーションがある
ヨーガン・アペロ『マネージメント 3.0』などでプラクティスを紹介
権限委譲していくことで、チームメンバーができることが増え、チームのアウトプットが増え、マネージャーのアウトプットも増える

どう委譲する?

少しチャレンジになるようなものを委譲していく
丸投げはNG
やり方は問わず、成果を問う
自分で手を動かさないため、不安になるかもしれない。
何でもコントロールしようとしない
自分でコントロールできないことを心配して、ストレスを溜めるのはやめること

チームメンバーの要求に答える

スタッフに合った仕事をうまく割り当てられるのが理想
本人のモチベーション、スキルの向上につながり、チームのアウトプットも向上
チームメンバーの特性に合わせて、仕事の割当、委譲方法などを調整する
発達の近接領域:助けがあれば取り組めるような領域にどんどん取り組めるような環境を作ったり、支援をする
AS-IS(現在地)とTO-BE(理想)の段階を刻み、発達の近接領域アプローチで順番に達成して、理想に近づく
1 on 1 で常に確認しながらやっていくのが好ましい

1 on 1

1 on 1で扱うトピックは多岐にわたる
- プロダクト、プロジェクト、目標設定、評価、キャリアなど
1 on 1 をうまく使いこなせるようになるのは、マネージャーとして非常に重要
月に1回の1 on 1ではチームメンバーの育成、パフォーマンスの改善やチームのアウトプットの向上には不十分
隔週、あるいは毎週が好ましい

人・人・人

転職できるぐらいに人を訓練し、転職したいと思わないくらいに厚遇せよ

リチャード・ブランソン

いい人を組織に定着させることが、最終的にアウトプットにつながっていく
マネージャーとしての本当に一番重要な仕事
- 人を大事にして、人に成長してもらって、パフォーマンスを発揮できるようにする

マネージャーはスタッフのために存在する

来週のスライド作ってて結論出た。
「マネージャーはスタッフのために存在する」

— Ryutaro YOSHIBA (@ryuzee) September 1, 2022

マネージャーはスタッフのために存在する
- チームメンバーに奉仕する人
- 1 on 1 も評価メンバーもスタッフのため
マネージャーとして問題のある行動
- 時間がないからと1 on 1を月1回とする
- 評価面談で、どういう仕事をしたのかヒアリング

EMのためのおすすめ二冊

書籍プレゼント企画あり

本イベントはForkwell主催です。

YouTube の概要欄にある所定の手続きを踏むことにより、キャンペーンの応募者全員に吉羽龍太郎氏が翻訳された『エンジニアリングマネージャーのしごと』がプレゼントされます。

キャンペーンの回答期限は 9月11日(日)23:59 JST です。

どしどし応募しましょう。

Q&A

EMに必要な技術力

全くエンジニアリング力がないのはまずい
普通に話ができる程度の技術力があれば大丈夫
技術的な意思決定は、テックリードなどがすれば良い
技術以外にも、コーチング、キャリア・ディベロップメントなどやるべきはたくさんある

エンジニアからリスペクトされるには?

技術力があるとわかりやすいが、技術的な会話ができればOK
普段の振る舞いが大事
Good
- 大人である。本人の行動が誠実、安定している、ロジカル。
- 例)チャットでいつも誰に対しても、同じトーンで丁寧で安定している
- 部門間の折衝でチームを守ってくれる
Bad
- 感情的、チームにいつもなにか押し付ける

EMのキャリアパス

『エンジニアのためのマネジメントキャリアパス』で触れられている
- EM→マネージャーのマネージャー→CTOというようにキャリアラダーを登る事が書かれている
どのポジションが偉いというわけではない
キャリアパスとして、ラダーを登るより、どのポジションをやりたいのか、自分がどうなりたいのかを考えたほうが良い
インディビジュアルコントリビューター(IC)とマネージャーそれぞれのトラックが存在したり、ICとマネージャーを行き来できるようなオプションがあるような環境が好ましい

EM/PM/PdM/テックリードのロールごとの責任分界点

世界的に共通の定義は存在しない
組織の中で、ロール・責任の考え方を一致させ、ポテンヒット、取りこぼしがないようにするのが大事
Scrum だと定義が明確なので、期待値のすり合わせがやりやすい

訓練した社員を引き止めるには?

スキルが上がるほど、市場価値も上がり、引く手あまたになるので、給料をあげないといけない
エンジニアは競争力の源泉の一つと認められている
アプローチは2種類
- EMが調整できる給料に制限があるときは、シニアマネージャーやCxOにエスカレーションして給与テーブルを見直す
- 自己実現のために、やりたい仕事をする機会を与える

プレイングマネージャー

中途半端はよくない
プライマリのロールの職責を十分に果たした上で、手を広げる。プライマリがなになのかも明確に
特に、マネージャーロールの職責が不十分だと、チーム全体に悪影響を及ぼす
複数のロールを持っていると、周りの人は、どのロールの観点で話しているか、わかりにくい

コーチング・スキル

Ryuzee氏が過去に在籍したベンダーでは、マネージャー向けのトレーニングがたくさんあり、トレーニングの内容も多岐にわたり、その一つのコーチングのトレーニングも含まれていた
会社として、マネージャーにはコーチング・スキルが重要なので、マネージャーになったらコーチングができるよう、プログラムに組み込まれていた
個人で受けている人もいる
コーチングは絶対に必要なわけではなくて、場合による

言語化能力

ナラティブ・言語化能力が大事
- 自然言語でチームのミッションや戦略を書く
書かないと、このスキルは向上しない
- 上位の役職者に添削してもらう、フィードバックループを繰り返す
Ryuzee氏が過去に在籍したクラウド・ベンダーはナラティブ文化
- チームの情報を共有する時はWord(PowerPointではない)で数ページにまとめ、ミーティングの冒頭で読み合わせ、その後、Q&Aする文化
- 文化を書く能力は必須だった
- Startups: How to Use Amazon’s Narrative Process to Set Goals and Think Clearly | AWS Startups Blog